Transport offload engines (TOE) are gaining popularity in high-speed systems for the purpose of optimizing throughput and lowering processor utilization. TOE components are often incorporated into one of various systems including printed circuit boards such as a network interface card (NIC), a host bus adapter (HBA), a motherboard; or in any other desired offloading context.
In recent years, the communication speed in networks has increased faster than processor speed. This increase has produced an input/output (I/O) bottleneck. The processor, which is designed primarily for computing and not for I/O, cannot typically keep up with the data flowing through networks. As a result, the data flow is processed at a rate slower than the speed of the network. TOE technology solves this problem by removing the burden from the processor (i.e. offloading processing) and/or I/O subsystem.
Prior art FIG. 1 illustrates a system 100 including both a host processor 102 and a transport offload engine 104 (i.e. TOE), in accordance with the prior art. In use, the transport offload engine 104 receives segmented data in packets via a network 116. Once received, the transport offload engine 104 stores the data in a TOE buffer 112, in order to provide time to generate a data available message 117 and send the message to the host processor 102. The foregoing operation of the transport offload engine 104 may be governed by control logic 114 of the transport offload engine 104.
In response to a data available message 117, the host processor 102 generates a data list object 106 [i.e. a scatter-gather list (SGL), etc.] that describes the location or locations in application memory 110 where the incoming data is ultimately to be stored. As shown, to accomplish this, the data list object 106 may include at least one memory start address where the data is to be stored, with each start address followed by the length of a region in memory.
In use, the host processor 102 generates and associates the data list object 106 with a socket (also known as a connection) associated with the received data that prompted the corresponding data available message 117. The incoming data is then be copied from the TOE buffer 112 to the application memory locations described by the corresponding data list object 106.
Thus, to receive a large amount of data via the network 116, the required size of the TOE buffer 112 may become excessively large. Unfortunately, a large TOE buffer 112 can not be implemented in a cost-effective manner on an integrated-circuit transport offload engine 104, since integrating on-board memory on the transport offload engine 104 is costly in terms of silicon die area, for example.
While there is a general desire to minimize, or even altogether eliminate, TOE buffer memory (i.e. see, for example, TOE buffer 112, etc.) on the transport offload engine 104, such an implementation is problematic. Specifically, without buffering incoming data using the TOE buffer 112, it is impossible for the aforementioned data available messages 117 to be generated and thus impossible to generate and allocate a data list object 106, which in turn prevents the storage of data in application memory.
There is thus an urgent need for a more cost-effective technique for managing and storing received data using data list objects (i.e. SGLs, etc.) in the context of a transport offload engine.